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Abstract — As the web grows and the amount of traffics on 
the web server increase, problems related to performance 
begin to appear. Some of the problems, such as the number 
of users that can access the server simultaneously, the num- 
ber of requests that can be handled by the server per sec- 
ond (requests per second) to bandwidth consumption and 
hardware utilization like memories and CPU. To give bet- 
ter quality of service (QoS), web hosting providers and also 
the system administrators and network administrators who 
manage the server need a benchmark application to mea- 
sure the capabilities of their servers. Later, the application 
intends to work under Linux/Unix — like platforms and built 
using Erlang/OTP Rll as a concurrent oriented language 
under Fedora Core Linux 5.0. WiiBench is divided into two 
main parts, the controller section and the launcher section. 
Controller is the core of the application. It has several du- 
ties, such as read the benchmark scenario file, configure the 
program based on the scenario, initialize the launcher sec- 
tion, gather the benchmark results from local and remote 
Erlang node where the launcher runs and write them in 
a log file (later the log file will be used to generate a re- 
port page for the sysadmin). Controller also has function 
as a timer which act as timing for user inters arrival to the 
server. Launcher generates a number of users based on the 
scenELrio, initialize them and start the benchmark by send- 
ing requests to the web server. The clients also gather the 
benchmark result and send them to the controller. 

Index Terms — Erlang, QoS, Network Management, Con- 
current Programming, Distribution 

I. Introduction 

IN the last two decades, human necessities in fast and 
accurate information create a lot of innovations in in- 
formation technology, one of them is the internet. Since 
TCP/IP released to pubUc in 1982 and World Wide Web 
(WWW) introduced in 1991, internet has became a pop- 
ular media to access and publish information. The easy 
to use web niec;hanisniH make people easy to search and 
publish information on the internet. The web service later 
grows to many aspects, such as entertainment, education, 
scientific research and many more. 

To access the web on the internet, we need a certain 
server than can provide user access on the web pages. This 
server is called web server or HTTP server and has a main 
duty to serve user access to web pages contents, either 
static or dynamic. 

As tli(^ web grows and the amount of traffics on the web 
server increase, problems related to performance begin to 
appear. Some of the problems, such as the number of users 
that can access the server simultaneously, the number of 
requests that can be handled by the server per second (re- 
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quests per second) to bandwidth consumption and hard- 
ware utilization like memories and CPU. 

To give better quality of service (QoS) , web hosting 
providers and also the system administrators and network 
administrators who manage the server need a benchmark 
application to measure the capabilities of their servers. 
Later, the application intends to work under Linux/Unix - 
like platforms and built using Erlang/OTP Rll as a con- 
current oriented language under Fedora Core Linux 5.0. 

Base on the above descriptions, there are some problems 
than can be summarized, such as: 

1. To give better Quality of Service, web hosting 
provider and also system administrators and network 
administrators who manage the web server need a 
benchmark application to measure the capabilities/ 
performances of their servers. 

2. The benchmark application is intended to be use by 
the network administrators and system administrators 
who work under Linux/Unix - like systems. 

3. The application is made by utilizing the concur- 
rent capability of Erlang programming language under 
Linux operating system. 

IL Theories 

A. Web Server 

The term web server can mean one of two things [2] : 

1. A computer or a number of computers wliic;li respon- 
sible for accepting HTTP requests from clients, which 
are known as web browsers, and serving them web 
pages, either static or dynamic pages. 

2. A computer program that provides the functionality 
described in the first sense of the term. 

Web server also works based on several standards, such 
as [2]: HTTP response to HTTP Request, Logging, Con- 
figurability, Authentication, Handling Static and Dynamic 
Contents, Modular Support, Virtual Hosts 

B. Erlang/OTP 

Erlang is a concurrent programming language with a 
functional core. By this we mean that the most impor- 
tant property of the language is that it is concurrent and 
that secondly, the sequential part of the language is a func- 
tional programming language. Concurrent means that the 
language has focus on how to makes multiple executions 
threads to run and do computational work together. In 
Erlang. these execution threads are called processes. The 
sequential sub-set of the language expresses what happens 
from the point it time where a process receives a message 
to the point in time when it emits a message. 



2 



The early version of Erlang was developed by Ericsson 
Computer Science Laboratory in 1985. During that time, 
Ericsson couldn't find an appropriate language that has 
high performance in concurrency especially for telecommu- 
nication applications programming (for switching, trunk- 
ing, etc), so they developed their own language. OTP 
stands for Open Telecom Platform, OTP was developed 
by Ericsson Telecom AB for programming next generation 
switches and many Ericsson products are based on OTP. 
OTP includes the entire Erlang development system to- 
gether with a set of libraries written in Erlang and other 
languages. OTP was originally designed for writing tele- 
coms application but has proved equally useful for a wide 
range of non-telecom that have concurrent, distributed, 
and also fault tolerant applications. In 1998 Ericsson re- 
leased Erlang and the OTP libraries as open source. Now, 
Erlang/OTP has reached the Rll version. 

III. Why We Use Erlang ? 

The simple answer to the question above that is we need 
concurrency in the benchmark application. The applica- 
tion must be able to generate multiple users to do some 
stress tests to the web server. 

But, there are some good features in Erlang, and even 
the other languages don't have these features. Some of 
these Erlang features are described below: 

1. In Erlang processes are light weight. 

2. Not only are Erlang processes light-weight, but also 
we can create many hundreds of thousands of such 
processes without noticeably degrading the perfor- 
mance of the system (unless of course they are all 
doing something at the same time) [5]. 

3. In Erlang, processes share no data and the only way 
in which they can exchange data is by explicit mes- 
sage passing, "dangling" pointers are very difficult 
to program in the presence of hardware failures - we 
took the easy way out, by disallowing all such data 
structures. [4] 

4. In Erlang, processes scheduling operation is done by 
its own virtual machine, so Erlang didn't inherit the 
underlying operating system processes scheduling. 

5. Real time. Erlang is intended for programming soft 
real-time systems where response times in the order 
of milliseconds are required. [4] 

6. Continuous operation. 

7. Automatic Memory management. 

8. Distribution. 

A. Concurrent and Distributed Erlang 

Concurrent in Erlang involves processes creation and 
deletion. In order to create a new process in Er- 
lang, we use BIF (Built In Function) spawn/3 : 
spawn (modulename , f unctionname , argument lists) 

or 

pid_variabe=spawn(modulenajne , f unctionncune , 
argument 1 i St s ) 

The illustration of process creation can be seen in figure 
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Fig. 1 

Process Creation Illustration 



A process which no longer need by the system will 
be automatically shutdown/delete by the virtual machine 
(Erlang Runtime System/ERTS). Meanwhile, the message 
parsing mechanism can be done by these codes : 



Pid ! Message, 



receive 
Message 1 -> 



Actions 1; 
Mess age 2 -> 



Actions2: 



after Time -> 



TimeOut Actions 



end 



H 



The illustration for message parsing can be seen in figure 







Fig. 2 

Message Parsing Illustration 



Besides the example that has been shown above, in Er- 
lang we can also use Behaviour in OTP Design Principles 
to create, delete and do message parsing between processes. 
A distributed Erlang system is a number of Erlang Run- 
time System (we called them nodes) that communicated 
each other by using message parsing with pid (process in- 
dentifier) through TCP/IP sockets transparently. A node 
must be given a name before it can communicate each 
other. The name is either a long name or a short name 
like the examples below: 

\$erl -name dilbert [long nernie] 
(dilbertOuab . ericsson . se) 1$>$ 
Oerl-snamie dilbert [short neime] 
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(dilbertOuab) 1$>$ 

A simple distribution in Eiiang can be done by these 
codes: 



Pid 

spawn(Fun@Node) 



alive (Node) 



not_alive(Node) 



B. Benchmark 

The term benchmark can be described as: 

1. A group of parameters in which products (software or 
hardware) can be measured the performance accord- 
ing to these parameters. 

2. A computer program designed to measure the perfor- 
mance of software or hardware according to certain 
parameters. 

3. A group of performance criteria that must be com- 
plied by software or hardware. 

Web server benchmark means that a benchmark activity 
is made to the web server to measure its performance based 
on several parameters and using certain computer program 
to do this activity. 

IV. Design 
A. WiiBench Concepts 

WiiBench is divided into two main parts, the controller 
section and the launcher section. 

Controller is the core of the application. It has several 
duties, such as read the benchmark scenario file, configure 
the program based on the scenario, initialize the launcher 
section, gather the benchmark results from local and re- 
mote Erlang node where the launcher runs and write them 
in a log file (later the log file will be used to generate a re- 
port page for the sysadmin). Controller also has function 
as a timer which act as timing for user inters arrival to the 
server. 

Launcher generates a number of user based on the sce- 
nario, initialize them and start the benchmark by sending 
requests to the web server. The clients also gather the 
benchmark result and send them to the controller. 

The illustration for WiiBench Concepts can be seen in 
figure |3] 

Several parameters that can be measured by this appli- 
cation are: 

1. Number of Requests per second. 

2. Simultaneous users that can be served by the server 
(per second). 

3. Time that needs to connect for the client so it can be 
connected to server. 

4. Number of user that can be served during the dura- 
tion of benchmark. 

5. Time that needs for a user so it can receive a full page 
of document /web page according to the request. 



6. Time that needs to complete a session (a group of 
requests) as described in the scenario. 

7. Network throughput. 

8. HTTP Status (200, 404). 

The application also has a report generator that written 
in PERL and using GNUPLOT to generate graphs based 
on the benchmark results from the log file. 




Fig. 3 

Illustration for, WiiBench Concepts 



B. The Scenario Files 

The benchmark scenario file is written using XML and 
consists of several sections: 

1. The server section, where the user (sysadmin) de- 
scribe the IP address of the server that he/she wants 
to benchmark. 

2. The client section, in this section, user can write the 
IP addresses where the launcher section starts and 
generate a numbers of clients. 

3. Inters arrival phase and benchmark duration section. 

4. The simulated user agents (web browser) section. 

5. The session and request section. 

Each of the section describes above can be modified ac- 
cording to user necessity. 

V. Implementation 

A. Hardware and Software Specifications 

WiiBench is implemented by using a simple topology 
consists of two computers and a server across Local Area 
Network in Kapuk Valley, Margonda, Depok. The two 
computers using an Intel Celeron Processor (1.8 GHz and 
2.28 GHz) and running Linux operating System (SuSE 10.0 
and Slackware Linux 11.0), Open SSH v2, Erlang/OTP 
Rll, PERL v5.8, and also BASH Shell. Both of them 
also connected to the TCP/IP network and within Kapuk- 
Valley domain (hostname mobile and posen-asik). The 
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server using an Intel Pentium II 400 MHz processor with 
768 megabytes SDRAM memories and running Slackware 
Linux 11.0 with Apache 2.0.55 web server. 

B. Testing and Implementation Process 

In this implementation process, we're going to make a 
benchmark scenario with these parameters: 

1. Total clients to generate: 600 clients. 

2. Benchmark duration: 10 minutes. 

3. Client inters arrival phase: 1 second. 

4. 300 clients will be generating in host mobile, mean- 
while the other 300 clients will be generate in host 
posen-asik. 

Before we run the program, we must generate a pair of 
authentication key (public and private) for passwordless 
authentication using SHH in order to get the Erlang nodes 
to communicate each other. 

[rootOmobile"] #ssh-keygeii -t rsa 

Enter file in which to save the key 
(/root/ . ssh/id_rsa) : 

Enter passphrase (empty for no passphrase) : 

Enter same passphrase again: 

Your identification has been saved in 
/root/ . ssh/ id_rsa . 

Your public key has been saved in 
/ root/ . ssh/ id_rsa . pub . 

The key fingerprint is: 

ec : 30 : 2c : c9 : eO : Oa : 92 : 48 : 3c : e5 : 5a : f 3 : 7c : 69 : d8 : 92 
rootOmobile .myownlinux . org 

[rootOmobile"] #scp /root/ . ssh/ id_rsa. pub 
rootOposen-asik: /root/ . ssh/ 

[rootOposen-asik] #echo .ssh/id_rsa.pub >> 
. ssh/authorizedJteys 

After the process above, we can start the benchmark 
process by executing the shell script to initialize and start 
the application. 

[root@mobile~] #/usr/local/bin/wii start 

Several results from the important parameters to exam- 
ine by the sysadmin are listed in the table below. 

Table 4.1 Benchmark Results 



Parameters 


Result 


Request per 


3.4 requests per 


Second 


second 


Connection 


1.8 connections 


per Second 


per second 


Page loaded 


1.8 pages per 


per second 


second 


Total user 


595 of 600 users 


served 





VI. Conclusions 

After our studies we show that in Erlang: 

1. Processes are light weight. Not only are Erlang pro- 
cesses light-weight, but also we can create many hun- 
dreds of thousands of such processes without notice- 
ably degrading the performance of the system (unless 
of course they are all doing something at the same 
time) , 



2. Processes share no data and the only way in which 
they can exchange data is by explicit message passing. 
Erlang message never contain pointers to data and 
since there is no concept of shared data, each process 
must work on a copy of the data that it needs. All 
synchronization is performed by exchanging messages. 

3. Processes scheduling operation is done by its own vir- 
tual machine. 

4. Processes are real time. Erlang is intended for pro- 
gramming soft real-time systems where response times 
in the order of milliseconds are required. 

5. Processes code has continuous operation. Erlang has 
primitives which allow code to be replaced in a run- 
ning system and allow old and new versions of code 
to execute at the same time. 

6. Processes operation use automatic memory manage- 
ment. Memory is allocated automatically when re- 
quired, and deallocated when no longer used. 

7. All interaction between processes is by asynchronous 
message passing. Distributed systems can easily be 
built. 

By examine the results based on the important param- 
eters; we hope that the syadmin and netadmin can make 
fine tuning to their server. 
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